Configuring SequeLink® Security on Linux, UNIX, and Windows

This section describes how to configure authentication, authorization, and data store logon for SequeLink for Linux, UNIX, and Windows.

Configuring Authentication for Data Access Activities

Set the ServiceAuthMethods service attribute to one or more of the following values:

You can configure multiple authentication mechanisms for data access activities. For example, if you configure ServiceAuthMethods=integrated_nt and ServiceAuthMethods=OSLogon(UID,PWD), the SequeLink Server uses the Integrated NT authentication mechanism and does not require an ODBC or ADO Client connecting from a Windows workstation to provide user ID and password information. SequeLink Clients on Linux/UNIX or a JDBC application still must provide a valid Windows user ID and password.

Configuring Authentication for Administrative Activities

To configure authentication for a SequeLink agent service, set the ServiceAdminAuthMethods service attribute to one or more of the following values:

For SequeLink services on Windows, you can configure multiple authentication mechanisms for administrative activities. For example, if you configure ServiceAdminAuthMethods=integrated_nt and ServiceAdminAuthMethods=OSLogon(UID,PWD), the SequeLink Server uses the Integrated NT authentication mechanism and does not require a SequeLink Manager running on a Windows workstation to provide user ID and password information. SequeLink Clients on Linux/UNIX still must provide a valid Windows user ID and password.

Configuring Single Sign-On Security

The combination of security features provided by SequeLink and the security provisions offered by the DBMS and the Linux, UNIX, and Windows operating systems allows you to configure a single sign-on environment for ODBC, JDBC, and ADO applications. Users log on to the security system on the network and can connect to the DBMS using their operating system credentials (if allowed by the DBMS security configuration).

Kerberos authentication provides single sign-on for ODBC, ADO, and JDBC applications on Linux, UNIX, and Windows. NT Integrated authentication provides single-sign on for ODBC and ADO applications on Windows only.

To configure single sign-on security:

  1. Configure your DBMS security as described in "Configuring SequeLink® Security on Linux, UNIX, and Windows".
  2. For instructions on how to configure your DBMS security, refer to your database documentation.

  3. Grant the required database access rights to users using the appropriate data store provided by your DBMS. For instructions on how to grant database access rights, refer to your database documentation.
  4. Choose one of the following authentication methods:
    • Kerberos. See "Configuring Kerberos Authentication" for details on configuring Kerberos authentication.
    • NT Integrated authentication. Set the ServiceAuthMethods or ServiceAdminAuthMethods service attribute to a value of integrated_nt.
  5. Restart the SequeLink Server.

NOTE: If SequeLink Client for ADO.NET clients will be connecting to this service, add another ServiceAuthMethods attribute, and specify ServiceAuthMethods=OSLogon(HUID,HPWD) or ServiceAuthMethods=OSLogon(UID,PWD). These SequeLink Clients must provide a valid server user ID and password.

Configuring Kerberos Authentication

Verify that your environment meets the requirements listed in Table 13-1 before you configure SequeLink for Kerberos authentication.

Table 13-1. Kerberos Authentication Requirements  
Component
Requirements
Database server
The database server must be running one of the following databases:
DB2:
  • DB2 v8.1 or higher for Linux/UNIX/Windows
Oracle:
  • Oracle 10g R2
  • Oracle 9i R2
Microsoft SQL Server:
  • Microsoft SQL Server 2005
  • Microsoft SQL Server 2000
In addition, your database security must be configured to accept operating system user IDs. See "Configuring Database Security" for more information.
Kerberos server
The Kerberos server is the machine where the user IDs for authentication are administered. The Kerberos server is also the location of the Kerberos KDC.

Configuring Database Security

To use single-sign on with Kerberos authentication, your database security must be configured to accept operating system user IDs:

For instructions on how to configure your DBMS security, refer to your database documentation.

Kerberos and Operating System User ID Mapping

A Kerberos user principal has the form:

name@REALM

To allow single-sign on for Kerberos in a SequeLink environment, the user principal name must be mapped to the operating system user ID. For example:

As a result, on Linux and UNIX, the database administrator must be aware that principals from different Kerberos realms, but with the same name, are mapped to the same operating system user ID. For example, the following principals are mapped to the same user ID:

user_A/@UVW.COM 

and

user_A/@XYZ.COM 

Configuring Kerberos Authentication for SequeLink® Server

  1. In your SequeLink data access service or your SequeLink Agent service, set ServiceAuthMethods attribute to a value of kerberos.
  2. In the server data source, set the DataSourceLogonMethod attribute to a value of OSIntegrated. This allows the SequeLink service to authenticate the client using the operating system user ID and password.


  3. If you installed the SequeLink Server on Windows, skip to Step 4.



  4. If you installed the SequeLink Server on Linux and UNIX, modify the krb5.conf file to contain your Kerberos realm name and the KDC name for that Kerberos realm. Modify the krb5.conf file by editing the file with a text editor.
  5. NOTE: In Windows Active Directory, the Kerberos realm name is the Windows domain name and the KDC name is the Windows domain controller name.

    For example, if your Kerberos realm name is XYZ.COM and your KDC name is kdc1, your krb5.conf file would look like this:

[libdefaults] 
        default_realm = XYZ.COM 
        default_keytab_name = FILE:/install_dir/lib/krb5/krb5.keytab 
        default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc 
        default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc 
[realms] 
        XYZ.COM = { 
             kdc = kdc1:88 
             admin_server = server1.eu.xyz.com:749 
             default_domain = kdc1 
        }; 
[domain_realm] 
        .xyz.com = XYZ.COM 
        .eu.xyz.com = XYZ.COM 
[logging] 
        kdc = FILE:/var/krb5/log/krb5kdc.log 
        admin_server = FILE:/var/krb5/log/kadmin.log 
        default = FILE:/var/krb5/log/krb5lib.log 
  1. (Optional) If you want to use a service principal name other than the default name to identify the SequeLink service, specify a value for the ServiceKerberosPrincipalName attribute for data access services or the ServiceAdminKerberosPrincipalName attribute for SequeLink Agent services. See "ServiceKerberosPrincipalName" and "ServiceAdminKerberosPrincipalName" for details.

Configuring Kerberos Authentication for the ODBC Client and ADO Client

If the SequeLink Client is installed on Windows, the Kerberos realm and KDC name for that realm are automatically detected by the Windows operating system.

NOTE: In Windows Active Directory, the Kerberos realm name is the Windows domain name and the KDC name is the Windows domain controller name.

If the SequeLink Client is installed on UNIX or Linux, you must modify a Kerberos configuration file named krb5.conf to specify values for the Kerberos realm and the KDC name for that realm. Typically, this file is installed by the Kerberos implementation provided by your UNIX or Linux operating system and is located in the /etc subdirectory of your UNIX or Linux machine.

For example, if your Kerberos realm name is XYZ.COM and your KDC name is kdc1, your krb5.conf file would look like this:

[libdefaults] 
        default_realm = XYZ.COM 
        default_keytab_name = FILE:/etc/krb5/krb5.keytab 
        default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc 
        default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc 
[realms] 
        XYZ.COM = { 
             kdc = kdc1:88 
             admin_server = server1.eu.xyz.com:749 
             default_domain = kdc1 
        }; 
[domain_realm] 
        .xyz.com = XYZ.COM 
        .eu.xyz.com = XYZ.COM 
[logging] 
        kdc = FILE:/var/krb5/log/krb5kdc.log 
        admin_server = FILE:/var/krb5/log/kadmin.log 
        default = FILE:/var/krb5/log/krb5lib.log 

Configuring Kerberos Authentication for the JDBC Client

During installation, the JDBC Client installs the following files required for Kerberos authentication in the /lib subdirectory of the SequeLink Client installation directory:

Obtaining a Kerberos Ticket Granting Ticket

To use Kerberos authentication, the application user first must obtain a Kerberos Ticket Granting Ticket (TGT) from the Kerberos server. The Kerberos server verifies the identity of the user and controls access to services using the credentials contained in the TGT.

If the application uses Kerberos authentication from a Windows client, the application user is not required to log onto the Kerberos server and explicitly obtain a TGT. Windows Active Directory automatically obtains a TGT for the user.

If an application uses Kerberos authentication from a UNIX or Linux client, the user must log onto the Kerberos server using the kinit command to obtain a TGT. For example, the following command requests a TGT from the server with a lifetime of 10 hours, which is renewable for 5 days:

kinit -l 10h -r 5d user 

where user is the application user.

Refer to your Kerberos documentation for more information about using the kinit command and obtaining TGTs for users.

Configuring Authorization for a SequeLink® Data Access Service

To configure user authorization for a SequeLink data access service, set the ServiceUser attribute, or, if you want to configure user authorization for user groups defined on Windows or UNIX, set the ServiceUserGroup attribute.

Configuring ServiceUser

To configure user authorization, set the ServiceUser attribute:

Configuring ServiceUserGroup

To configure user authorization for user groups defined on a Linux, UNIX, and Windows server, set the ServiceUserGroup attribute. Specify ServiceUserGroup=user_group, where user_group is a valid user group defined on Linux, UNIX, and Windows. To configure user authorization for multiple user groups, you must set this attribute multiple times, one instance for each user. For example:

ServiceUserGroup=SLUSERG1 
ServiceUserGroup=SLUSERG2 
ServiceUserGroup=SLUSERG3 

NOTE: On Windows servers, you must prefix the user group ID with the Windows server name or the Windows domain name where the user group is defined, for example, SALES\SLUSERG1. When connecting, the user must also prefix the administrator ID with the Windows server name, if connecting to a local server, or the Windows domain name.

Configuring Authorization for a SequeLink® Agent Service

To configure administration authorization, set the ServiceAdministrator service attribute, or, if you want to configure authorization for user groups defined on Linux, UNIX, and Windows, set the ServiceAdministratorGroup service attribute.

NOTE: On Windows, each user who is allowed to make SequeLink Manager requests must have administrator rights.

Configuring ServiceAdministrator

To configure administration authorization, set the ServiceAdministrator attribute:

Configuring ServiceAdministratorGroup

To configure authorization for user groups defined on Windows and UNIX, set the ServiceAdministratorGroup attribute. Specify ServiceAdministratorGroup=user_group, where user_group is a valid user group defined on Windows or UNIX. To configure administration authorization for multiple user groups, you must set this attribute multiple times, one instance for each user. For example:

ServiceAdministratorGroup=SLUSERG1 
ServiceAdministratorGroup=SLUSERG2 
ServiceAdministratorGroup=SLUSERG3 

NOTE: On Windows servers, you must prefix the user group ID with the Windows server name or the Windows domain name where the group is defined, for example, SALES\SLUSERG1. When connecting, the user must also prefix the user group with the Windows server name, if connecting to a local server, or the Windows domain name.

Configuring Data Privacy

To ensure privacy of data, SequeLink provides data scrambling (all SequeLink environments) and "real" encryption through the use of SSL.

Configuring Data Scrambling

To configure SequeLink to use DES, 3DES, or byteswap, you must set the "ServiceEncryptionAlgorithm" service attribute, for example, ServiceEncryptionAlgorithm=DES. Data scrambling is not enabled by default, which means that if you do not configure data scrambling, cleartext messages are transmitted between the client and server over the network.

Configuring SSL Encryption

SequeLink supports SSL for the following types of data transfers:

The configuration process is different for each data transfer type.

Data Transfers Between SequeLink Client and SequeLink Server

By default, when SSL encryption is enabled, SSL uses the TLS_DH_anon_WITH_AES_128_CBC_SHA cipher suite for data encryption. If you want to change the cipher suite used for SSL, set a value for the ServiceSSLCipherSuites service attribute. See "ServiceSSLCipherSuites" for a description of valid values.

Because creating an SSL session requires CPU-intensive computations, SSL session reuse results in a relatively large performance gain over setting up completely new security sessions for each connection. Cached sessions allow the client to reuse a session in a subsequent connection. The "ServiceSSLSessionCacheSize" service attribute controls how many entries can be cached. Set this attribute to a number less than or equal to the maximum connections setting for the server. The "ServiceSSLSessionCacheTimeout" value specifies how long cached session IDs remain valid.

To configure SSL data encryption:

  1. Enable SSL encryption on the SequeLink Server. Set the ServiceSSLEnabled service attribute to true.
  2. Enable SSL encryption on the SequeLink Client:
    • JDBC Client: Using a connection URL, specify a value of 1 for the Encrypted connection property. For example:
    • jdbc:sequelink://localhost:16007;DatabaseName=odbc;
      Encrypted=1

    • ODBC Client: Using the ODBC Administrator, on the General tab, select the Encrypted (SSL) check box. Alternatively, you can use the Encrypted connection attribute in the connection string. For example:
    • DSN=sqlnk600_sqlsrv;SDSN=Default;HST=localhost;PRT=16007;DB=odbc;UID=odbc;PWD=sqlnk001;Encrypted=1

    • ADO Client: On the DataDirect SequeLink for ADO 6.0 Provider dialog box, on the General tab, select the Encrypted (SSL) check box. Alternatively, you can use the Encrypted connection attribute in the provider string. For example:
    • DSN=sqlnk600_sqlsrv;SDSN=Default;HST=localhost;PRT=16007;DB=odbc;UID=odbc;PWD=sqlnk001;Encrypted=1

Alternatively, if you are using LDAP in your SequeLink environment, you can configure SSL encryption as shown in the following examples. The LDAP attribute used to configure encryption depends on whether you are configuring an LDAP entry for the JDBC, ODBC, or ADO client.

Example 1: LDAP Entry for the JDBC Client

Configure SSL encryption using the JavaReferenceAddress attribute (javaReferenceAddress: #5#encrypted#1).

dn: cn=DB2V8 on server1,ou=JVS,ou=Arne,ou=USERS,o=Development 
cn: DB2V8 on server1 
objectClass: top 
objectClass: javaContainer 
objectClass: javaObject 
objectClass: javaNamingReference 
javaReferenceAddress: #0#description# 
javaReferenceAddress: #1#portNumber#6007 
javaReferenceAddress: #2#serverName#server1 
javaReferenceAddress: #3#databaseName#jvs 
javaReferenceAddress: #4#serverDataSource#Default 
javaReferenceAddress: #5#encrypted#1 
javaFactory: com.ddtek.jdbcx.sequeLink.SequeLinkDataSourceFactory 
javaClassName: com.ddtek.jdbcx.sequelink.SequeLinkDataSource 

Example 2: LDAP Entry for the ODBC Client or the ADO Client

Configure SSL encryption using the SequelinkEncrypted attribute (SequeLinkEncrypted: 1).

# usercn.ldiff template 
# USER     Arne 
# DATABASE SequeLink 
# HOST     belg-keidis 
# PORT     6007 
# 
dn: cn=DB2V8 on belg-keidis,ou=OVS,ou=Arne,ou=USERS,o=Development 
cn: DB2V8 on belg-keidis 
objectClass: top 
objectClass: SequeLinkODBCDSN 
SequeLinkPort: 6007 
SequeLinkHost: belg-keidis 
SequeLinkServerDatasource: Default 
SequeLinkEncrypted: 1  
Data Transfers Between the JDBC Client and the SequeLink Proxy Server

For details on configuring SSL encryption for data transfers between the JDBC Client and the SequeLink Proxy Server, see "Configuring the SequeLink® Proxy Server".

Configuring Data Store Logon

A client application establishing a connection to the database must provide a valid DBMS user ID and password when DataSourceLogonMethod=DBMSLogon(UID,PWD) or DataSourceLogonMethod=DBMSLogon(DBUID,DBPWD).

Depending on how the SequeLink service is configured, the SequeLink Server may require the SequeLink Client to provide two user IDs and passwords. SequeLink Clients typically provide user ID and password information using the UID and PWD attributes in a connection string (ODBC and ADO) or a connection URL (JDBC).

To avoid possible conflict with a standard keyword pair (UID,PWD) with two sets of values, make sure that you set non-conflicting values for the ServiceAuthMethods and DataSourceLogonMethod attributes. For example, when ServiceAuthMethods=OSLogon(UID,PWD) and DataSourceLogonMethod=DBMSLogon(DBUID,DBPWD), the SequeLink Client must provide the operating system user and password using the keywords UID and PWD and the database user and password must be specified using the DBUID and DBPWD keywords.

To allow the DBMS to inherit the operating system (or network) user ID and password for data store authorization, specify DataSourceLogonMethod=OSIntegrated. For example, you may want to specify DataSourceLogonMethod=OSIntegrated to allow Kerberos to use the operating system user Id and password for authentication.

NOTE: Do not use this method when ServiceAuthMethods=anonymous.

Some databases allow anonymous access, that is, access without any user credentials. To allow anonymous access to the database, specify DataSourceLogonMethod=anonymous.

Storing Client Credentials

The credentials for the ODBC Client can be stored in the registry on Windows or in the odbc.ini on Linux/UNIX. This allows the user to logon without specifying credentials.

Storing Credentials in the Windows Registry

The following keys are added:

HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\<dsname>\LogonId 
HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\<dsname>\Password  
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\<dsname>\LogonId 
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\<dsname>\Password 

The slencpwd.exe utility is installed in the Client's installation directory. This utility allows the customer to enter an encrypted password in the registry and optionally add a LogonId. The LogonId is stored a plain text, the Password is encrypted. Note that the credentials are always sent over the wire in encrypted form.

C:\>slencpwd 
SequeLink Client for ODBC (tm) Utility to store an encrypted password in a 
Data Source 
Choose System DSN [S] or User DSN [U]. 
Choice: [U] ==> U 
Enter Data Source Name: sqlnk600_mydsn 
Choose which password to encrypt and store. 
[1]=Password (PWD) 
[2]=DBPassword (DBPWD) 
[3]=HPassword (HPWD) 
[4]=NewPassword (NPWD) 
Choice: [1] ==> 1 
Enter Password (PWD) (keystrokes are not shown): 
DSN=sqlnk600_mydsn : Password (PWD) stored encrypted. 
Would you like to store a LogonID (UID) as well? [Y] [N] 
Choice: ==> Y 
Enter LogonID (UID):odbc 
DSN=sqlnk600_mydsn : LogonID (UID) stored. 

Storing Client Credentials in the odbc.ini file

The slencpwd utility is installed in the tools directory of the driver's installation directory. This utility allows you to enter an encrypted password in the odbc.ini and, optionally, to add a LogonId.

The following keys are added to the odbc.ini:

LogonId=my_logonid 
Password=my_password_in_encrypted_format 

The LogonId is stored plain text while the Password is encrypted. Note that the credentials are always sent over the wire in encrypted form.

$ ./slencpwd 
SequeLink Client for ODBC (tm) Utility to store an encrypted password in a 
Data Source 
Enter Data Source Name: sqlnk600_mydsn 
Choose which password to encrypt and store. 
[1]=Password (PWD) 
[2]=DBPassword (DBPWD) 
[3]=HPassword (HPWD) 
[4]=NewPassword (NPWD) 
Choice: [1] ==> 1 
Enter Password (PWD) (keystrokes are not shown): 
DSN=sqlnk600_mydsn : Password (PWD) stored encrypted. 
Would you like to store a LogonID (UID) as well? [Y] [N] 
Choice: ==> Y 
Enter LogonID (UID):my_logonid 
DSN=sqlnk600_mydsn : LogonID (UID) stored. 

SequeLink® Security Attribute Defaults for Linux, UNIX, and Windows

This section lists the installation defaults for SequeLink's security attributes for Linux, UNIX, and Windows and describes the effect each combination of settings has on security.

Defaults for a SequeLink® Agent Service

ServiceAdminAuthMethods=OSlogon(UID,PWD) 
ServiceAdministrator=SequeLink_administrator 

The combination of defaults for these attributes means that only the person who logs on using the user ID that was entered when the SequeLink Server software was installed is allowed to manage the SequeLink environment. The SequeLink Server installer prompts for a user ID for the SequeLink administrator when you install the SequeLink Server. On Windows, the SequeLink administrator must have administrator rights.

ServiceEncryptionAlgorithm=none 

The default for this attribute means that cleartext messages are transmitted between the client and server. Note that user IDs and passwords are never sent as cleartext.

Defaults for a Data Access Service

ServiceAuthMethods=anonymous 
ServiceUser=everyone 
DataSourceLogonMethod=DBMSLogon(UID,PWD) 
DataSourceReadOnly=No 

The combination of defaults for these attributes means that anyone who can provide a valid DBMS user name and password will be allowed to access the database using this service. The database connection accepts all types of SQL statements. Once connected to the DBMS, the database security system will guarantee that the user can only perform actions that are allowed by the database administrator.

ServiceEncryptionAlgorithm=none 

The default for this attribute means that cleartext messages are transmitted between the client and server. Note that user IDs and passwords are never sent as cleartext.